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Abstract 

Most  systems  designed  for  the  symbolic  verification  of  security  protocols  operate  under  the  unproved  assumption  that  an 
attack  can  only  result  from  the  combination  of  a  fixed  number  of  message  transformations,  which  altogether  constitute  the 
capabilities  of  the  so-called  Dolev-Yao  intruder.  In  this  paper,  we  show  that  the  Dolev-Yao  intruder  can  indeed  emulate  the 
actions  of  an  arbitrary  symbolic  adversary.  In  order  to  do  so,  we  extend  MSR,  a  flexible  specification  framework  for  security 
protocols  based  on  typed  multiset  rewriting,  with  a  static  check  called  data  access  specification  and  aimed  at  catching 
specification  errors  such  as  a  principal  trying  to  use  a  key  that  she  is  not  entitled  to  access. 


1  Introduction 

Cryptographic  protocols  are  increasingly  used  to  secure  transactions  over  the  Internet  and  protect  access  to  computer 
systems.  Their  design  and  analysis  are  notoriously  complex  and  error-prone.  Sources  of  difficulty  include  subtleties  in  the 
cryptographic  primitives  they  rely  on,  and  their  deployment  in  distributed  environments  plagued  by  powerful  and  oppor¬ 
tunistic  attackers.  Most  systems  designed  for  protocol  analysis,  e.g.  [1,  5,  14,  16,  20]  circumvent  the  first  issue  by  relying 
on  a  symbolic  idealization  known  as  the  Dolev-Yao  model  of  security  [15,  21]:  the  cryptography  is  assumed  to  be  flawless, 
which  permits  viewing  message-forming  operations  such  as  encryption  as  symbolic  combinators  ultimately  applied  to  atomic 
abstractions  of  principal  names,  keys,  nonces,  etc,  rather  than  to  bit-strings.  Systems  that  adopt  the  Dolev-Yao  idealization 
achieve  relative  tractability  by  empowering  their  attacker  model  with  a  fixed  set  of  basic  capabilities,  altogether  known  as  the 
Dolev-Yao  intruder.  It  is  a  commonly  held,  but  unproved,  belief  that  this  model  is  sufficient  to  expose  any  attack  that  can  be 
mounted  by  a  symbolic  adversary,  i.e.  one  playing  by  the  rules  of  the  Dolev-Yao  abstraction,  but  otherwise  arbitrary. 

MSR  originated  as  a  simple  logic-oriented  language  aimed  at  investigating  the  decidability  of  protocol  analysis  within  the 
Dolev-Yao  model  [11].  It  evolved  into  a  precise,  powerful,  flexible,  and  still  relatively  simple  framework  for  the  specification 
of  complex  cryptographic  protocols,  possibly  structured  as  a  collection  of  coordinated  subprotocols  [8,  9,  7].  It  uses  strongly- 
typed  multiset  rewriting  rules  over  first-order  atomic  formulas  to  express  protocol  actions  and  relies  on  a  form  of  existential 
quantification  to  symbolically  model  the  generation  of  nonces  and  other  fresh  data.  It  supports  an  array  of  useful  static  checks 
that  include  type-checking  [8].  An  earlier  version  of  MSR  fuels  the  CAPSL  authentication  protocol  verification  tool  in  the 
form  of  the  underlying  CIL  intermediate  language  [14]. 

In  this  paper,  we  use  MSR  as  a  formal  tool  to  study  the  very  nature  of  the  Dolev-Yao  intruder,  and  ultimately  to  show 
that  it  subsumes  any  other  attacker  that  follows  the  Dolev-Yao  abstraction.  In  order  to  do  so,  we  endow  MSR  with  a  novel 
static  check,  data  access  specification  (DAS),  aimed  at  enforcing  such  sensible  requirements  as,  for  example,  that  a  principal 
may  access  the  public  key  of  any  other  principal,  but  in  general  not  their  private  keys.  The  natural  MSR  specification  of  the 
Dolev-Yao  intruder  is  shown  not  only  to  satisfy  the  data  access  policy,  but  in  doing  so  to  make  use  of  every  facet  of  it.  This 
highlights  subtle  constraints  on  the  Dolev-Yao  intruder  model  that  are  typically  not  exposed  by  other  approaches.  Since, 
differently  from  most  proposals,  MSR  allows  specifying  an  arbitrary  attacker  using  the  same  syntax  as  a  regular  protocol,  we 
can  provide  an  effective  construction  that  shows  that  our  formalization  of  the  Dolev-Yao  intruder  can  emulate  the  deeds  of 
every  adversary  that  satisfies  the  typing  and  data  access  policies  of  MSR. 
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The  available  tools  designed  to  offer  automated  support  to  security  protocol  verification  [4,  14,  18,  20,  22,  24,  25]  provide 
a  limited  array  of  static  checks,  often  just  type-checking  for  simple  types.  In  particular,  we  are  not  aware  of  any  proposal 
that  enforces  DAS.  Moreover,  while  nearly  all  approaches  rely  on  some  variant  of  the  Dolev-Yao  intruder,  we  could  not  find 
a  formal  proof  in  the  literature  that  this  model  indeed  implements  the  most  powerful  symbolic  attacker.  Finally,  it  should  be 
observed  that  our  notion  of  data  access  specification  is  orthogonal  to  the  insightful  guidelines  of  [2,  27],  aimed  at  constructing 
protocols  that  are  immune  by  design  to  certain  classes  of  attack. 

The  main  contributions  of  this  paper  are:  1)  the  definition  of  a  decidable  notion  of  DAS  for  MSR  that  is  preserved  by 
execution;  2)  the  formal  definition  of  the  concept  of  a  generic  symbolic  attacker,  based  on  DAS,  and  the  formalization  of  the 
Dolev-Yao  intruder;  3)  a  proof  highlight  that  the  Dolev-Yao  intruder  model  can  emulate  an  arbitrary  attacker  that  satisfies  the 
data  access  policy  (the  full  proof  can  be  found  in  [6]).  This  paper  is  about  the  specification  of  cryptographic  protocols,  not 
about  protocol  analysis. 

This  paper  is  structured  as  follows:  in  Section  2,  we  carefully  recall  the  form  of  an  MSR  specification.  Its  DAS  policy, 
a  major  novelty  of  this  paper,  and  the  relative  decidability  results  are  the  subject  of  Section  3.  In  Section  4,  we  present  the 
execution  model  of  our  framework  and  prove  that  it  preserves  access  control.  In  Section  5,  we  formalize  the  Dolev-Yao 
intruder  in  MSR  and  in  Section  6  we  prove  that  it  can  emulate  the  actions  of  an  arbitrary  attacker.  Section  7  hints  at  directions 
of  future  work. 

2  MSR 

In  the  past,  cryptoprotocols  have  often  been  presented  as  the  temporal  sequence  of  messages  being  transmitted  during 
a  “normal”  mn.  Recent  proposals  champion  a  view  that  places  the  involved  parties  in  the  foreground.  A  protocol  is  then 
a  collection  of  independent  roles  that  communicate  by  exchanging  messages,  without  any  reference  to  runs  of  any  kind. 
A  role  has  an  owner,  the  principal  that  executes  it,  and  specifies  the  sequence  of  messages  that  he/she  will  send,  possibly 
in  response  to  receiving  messages  of  some  expected  form.  MSR  adopts  and  formalizes  this  perspective.  A  role  is  given 
as  a  parameterized  collection  of  multiset  rewrite  rules  that  encode  the  expected  message  receptions  and  the  corresponding 
transmission.  An  illustrative  example  can  be  found  in  Appendix  A.  Rule  firing  emulates  receiving  (and  accepting)  a  message 
and/or  sending  a  message.  The  messages  in  transit,  the  actions  and  information  available  to  the  roles,  and  other  data  constitute 
the  state  of  execution  of  a  protocol.  Rules  implement  partial  transformations  between  states.  Their  applicability  is  constrained 
by  the  contents  of  the  current  state.  Execution  is  preceded  by  static  type-checking  [8]  and  DAS  validation  (see  Section  3) 
which  limits  the  number  of  run-time  checks  and  allows  catching  common  specification  errors  early. 

2.1  Messages 

Messages ,  or  more  properly  terms ,  are  obtained  by  applying  a  number  of  message  forming  constructs,  discussed  below,  to 
a  variety  of  atomic  messages.  The  atomic  messages  we  will  consider  in  this  paper  are  principal  identifiers,  keys,  nonces,  and 
raw  data  (i.e.  information  that  have  no  other  function  in  a  protocol  than  to  be  transmitted): 

Atomic  messages:  a  ::=  A  (Principal) 

|  k  (Key) 
n  (Nonce) 
m  ( Raw  datum) 

Although  we  will  limit  our  discussion  to  these  kinds  of  atomic  messages,  it  should  be  noted  that  others  can  be  accommodated 
by  extending  the  appropriate  definitions  [9],  The  message  constructors  we  will  consider  are  concatenation,  shared-key 
encryption,  and  public-key  encryption: 

Messages:  t  ::=  a  (Atomic  messages) 

x  ( Variables ) 

t\  t-2  ( Concatenation ) 

{/}k  (Symmetric-key  encryption) 

1/1  k  (Asymmetric-key  encryption) 

Observe  that  we  use  a  different  syntax  for  shared-key  and  public-key  encryption.  We  could  have  identified  them,  as  done  in 
many  approaches.  We  choose  instead  to  distinguish  them  to  show  the  flexibility  and  precision  of  our  technique.  Again,  other 
constructors,  for  example  hash  functions  and  digital  signatures  [9],  can  easily  be  accommodated  by  extending  the  appropriate 
definitions.  Their  inclusion  would  lengthen  the  discussion  without  introducing  substantially  new  concepts. 
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A  parametric  message  allows  variables  wherever  terms  could  appear.  We  will  write  A  (or  B),  k,  n  and  to,  variously 
decorated,  for  atomic  constants  or  variables  that  are  principals,  keys,  nonces  and  raw  data,  respectively.  Whenever  the  object 
we  want  to  refer  to  cannot  be  but  a  constant,  we  will  use  the  corresponding  seriffed  letters:  A  (or  B),  k,  n  and  m.  Instead,  the 
letters  x,  y  and  2  will  stand  for  terms  that  must  be  variable.  Constants  and  variables  constitute  the  class  of  elementary  terms , 
denoted  with  the  letter  e.  Finally,  we  write  [ t/x\t '  for  the  substitution  of  a  variable  x  with  a  term  t  in  another  term  t'  [7], 

2.2  Message  Predicates  and  States 

States  are  a  fundamental  concept  in  MSR:  they  are  the  central  constituent  of  the  configurations  of  a  protocol  execution; 
they  are  the  objects  transformed  by  rewrite  rules  to  simulate  message  exchange  and  information  update;  finally,  together  with 
execution  traces,  they  are  the  hypothetical  scenarios  on  which  protocol  analysis  is  based.  A  state  is  a  finite  collection  of 
atomic  first-order  formulas  called  message  predicates  i.e.  predicate  symbols  applied  to  an  ordered  sequence  of  terms: 

Message  tuples  t  ::=  •  (Empty  tuple) 

t,  t  (Tuple  extension) 

Three  kinds  of  predicates  can  enter  a  state  or  a  rewrite  rule:  First,  the  predicate  N(_)  implements  the  contents  of  the 
public  network  in  a  distributed  fashion:  for  each  (ground)  message  t  currently  in  transit,  the  state  will  contain  a  component 
of  the  form  IM(t).  Second,  roles  rely  on  a  number  of  role  state  predicates ,  generally  one  for  each  of  their  rules,  of  the  form 
Li  (_,... ,  _),  where  l  is  a  unique  identifying  label.  The  arguments  of  this  predicate  record  the  value  of  known  parameters  of 
the  execution  of  the  role  up  to  the  current  point.  Third,  a  principal  A  can  store  data  in  private  memory  predicates  of  the  form 
M  4  (_. ...,_)  that  survives  role  termination  and  can  be  used  across  the  execution  of  different  roles,  as  long  as  the  principal 
stays  the  same.  Memory  predicates  are  useful  in  modeling  situations  that  need  to  maintain  data  private  across  role  executions: 
for  example,  they  allow  a  principal  to  remember  his  Kerberos  ticket  [9],  or  the  trusted-third-party  of  a  fair  exchange  protocol 
to  avoid  fraudulent  recoveries  from  aborted  transactions.  They  are  also  used  to  encapsulate  such  entities  as  local  clocks  [9], 
Finally,  they  allow  an  intruder  to  accumulate  knowledge  to  be  used  in  mounting  attacks,  as  described  in  Section  5. 

A  state  is  a  finite  collection  of  ground  message  predicates,  as  formalized  in  the  following  grammar: 

States:  S  ::=  •  (Empty  state) 

S,  N(i)  (Extension  with  a  network  predicate) 

S,  L i(t)  (Extension  with  a  role  state  predicate) 

S,  MA(f)  (Extension  with  a  memory  predicate) 

We  interpret  the  extension  construct  as  a  multiset  union  operator,  abstracting  in  this  way  from  the  order  of  the  component 
predicates  of  a  state. 

Protocol  rules  transform  states  by  removing  a  number  of  component  predicates,  and  adding  other,  usually  related,  state 
elements.  The  antecedent  and  consequent  of  a  rewrite  rule  embed  therefore  parametric  substates  whose  variables  are  instanti¬ 
ated  at  application  time.  However,  role  state  predicates  need  to  be  created  on  the  spot  in  order  to  avoid  interferences  between 
concurrently  executing  role  instances.  We  achieve  this  by  introducing  variables,  denoted  L,  that  are  instantiated  to  actual  role 
state  predicates  during  execution. 

2.3  Types 

Typing  is  available  in  MSR ,  as  in  many  languages,  as  a  mechanism  for  abstracting  away  aspects  of  a  specification  con¬ 
sidered  too  low-level.  In  the  case  of  a  protocol,  we  are  abstracting  the  method  by  which  a  principal  distinguishes  objects  of 
a  different  nature  and  categorizes  them:  for  example  field  lengths,  redundancy,  database  accesses,  trusted  subprotocols,  etc. 
MSR  offers  simple  yet  powerful  means  to  express  this  abstraction.  However,  it  is  ultimately  the  specifier  who  is  in  charge  of 
laying  out  a  sensible  set  of  types  for  a  protocol,  and  in  particular  to  avoid  the  danger  of  over-abstraction. 

The  typing  machinery  of  MSR  [8]  is  based  on  the  type-theoretic  notion  of  dependent  product  types  with  subsorting  [12, 
17,  3,  23].  In  this  paper,  we  use  the  following  types  to  classify  terms: 

Types:  r  ::=  principal  (Principals) 

nonce  (Nonces) 

shK  AB  (Shared  keys) 

p  u  b  K  A  (Public  keys ) 

privK  k  (Private  keys ) 

msg  ( Messages ) 
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The  types  “principal”  and  “nonce”  classify  principals  and  nonces,  respectively.  The  next  three  productions  allow  distin¬ 
guishing  between  shared  keys,  public  keys  and  private  keys.  Dependent  types  offer  a  simple  and  flexible  way  to  express  the 
relations  that  hold  between  keys  and  their  owner  or  other  keys.  A  key  “k”  shared  between  principals  “A”  and  “B”  will  have 
type  “shK  A  B”.  Here,  the  type  of  the  key  depends  on  the  specific  principals  “A”  and  “B”.  Similarly,  a  constant  “k”  is  given 
type  “pubK  A”  to  indicate  that  it  is  a  public  key  belonging  to  “A”.  We  use  dependent  types  again  to  express  the  relation 
between  a  public  key  and  its  inverse.  Continuing  with  the  last  example,  the  inverse  of  “k”  will  have  type  “privK  k”. 

We  use  the  type  msg  to  classify  generic  messages.  Clearly  raw  data  have  type  msg.  This  is  however  not  sufficient  since 
nonces,  keys,  and  principal  identifiers  are  routinely  part  of  messages.  We  address  this  issue  by  imposing  a  subsorting  relation 
between  types,  formalized  by  the  judgment  “r  ::  t'”  (read  r  is  a  subsort  of  t').  In  this  paper,  the  subsorting  relation  will 
amount  to  having  each  of  the  types  discussed  above  be  a  subtype  of  msg.  Its  extension  can  be  found  in  Appendix  B. 

Again,  the  above  types  should  be  thought  of  as  a  reasonable  instance  of  our  approach  rather  than  the  approach  itself.  Other 
schemas  can  be  specified  by  defining  appropriate  types  and  how  they  relate  to  each  other.  For  example,  digital  signatures 
can  be  accommodated  by  introducing  dedicated  dependent  types  akin  to  “pubK  A”  and  “privK  k”  [9],  An  untyped  setting  is 
obtained  by  ascribing  type  msg  to  every  entity.  On  the  other  hand,  other  applications  may  find  convenient  to  define  distinct 
types  for  long-term  keys  and  have  them  not  be  a  subsort  of  msg,  prohibiting  in  this  way  the  transmission  of  long-term  secrets 
as  parts  of  messages  [8], 

We  use  dependent  Cartesian  product  types,  here  called  dependent  type  tuples,  to  classify  term  tuples  and  consequently 
predicate  symbols.  These  objects  are  defined  as  follows: 

Type  tuples  t  ::=  •  (Empty  tuple) 

r(a:)  x  t  (Type  tuple  extension) 

The  notation  <xl  on  the  left  of  the  Cartesian  product  symbol  binds  the  variable  x  in  the  type  tuple  t  to  its  right.  Dependencies 
allow  capturing  fine  associations  between  arguments,  such  as  between  a  principal  and  his/her  own  public  key:  for  example 
the  type  tuple  “principal1'4-*  x  pubK  A”  will  only  classify  pairs  (A,  k)  where  k  is  the  public  key  of  A.  Given  a  dependent  tuple 
type  x  r,  we  will  drop  the  label  -Xl  whenever  the  variable  x  does  not  occur  (free)  in  t.  Examples  of  dependent  tuples 
can  be  found  in  Appendix  A. 

Ground  objects  are  type-checked  against  a  signature,  defined  as  a  list  of  type  declarations  for  atomic  constants  and  memory 
and  role  state  predicate  symbols  (the  network  predicate  is  hardwired  in  MSR ): 

Signatures  E  ::=  •  (Empty  signature) 

a  :  t  (Atomic  message  declaration) 

E,  L/  :  t  (Local  state  predicate  declaration) 

E,  M_  :  t  (Memory  predicate  declaration) 

Objects  containing  variables  rely  instead  on  a  typing  context,  defined  as  a  signature  extended  with  declarations  for  variables 
and  role  state  predicate  parameters: 

Typing  context  T  ::=  E  (Plain  signature) 

T,x  :  t  (Variable  declaration) 

r,  L  :  t  (Role  state  predicate  parameter  declaration) 

We  assume  that  each  object  in  a  signature  (or  context)  is  declared  exactly  once.  We  promote  to  denote  union.  This 
operation  is  defined  only  if  the  resulting  sequence  does  not  contain  multiple  declaration  for  the  same  object. 

The  typing  judgments  and  rules  of  MSR  are  thoroughly  analyzed  in  [8]  and  summarized  in  Appendix  B.  In  the  sequel,  we 
will  make  use  of  the  typing  judgments  for  terms  “E  h  t:  r”,  signatures  “h  E”  and  states  “E  h  S”.  Binary  judgments 
“E  I  X ”  will  also  be  used  for  entities  X  still  to  be  introduced,  in  particular  rules,  protocol  theories,  and  active  role  sets. 
Type-checking  MSR  specifications  has  been  proved  decidable  in  [8], 

2.4  Rules 

Rules  are  the  basic  mechanism  that  enables  the  transformation  of  one  state  into  another,  and  therefore  the  simulation 
of  protocol  execution:  whenever  the  antecedent  matches  part  of  the  current  state,  this  portion  may  be  substituted  with  the 
consequent  (after  some  processing).  Protocol  rules  are  generally  parametric  so  that  the  same  rule  can  be  used  in  a  number  of 
slightly  different  scenarios  (e.g.  without  fixing  interlocutors  or  nonces).  Therefore  a  typical  rule  mentions  variables  that  are 
instantiated  to  actual  terms  during  execution.  We  introduce  them  by  means  of  typed  universal  quantifiers: 

Rule:  r  ::=  Ihs  — »  rhs  (Rule  core) 

\/x:r.r  (Parameter  closure) 
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Free  variables  can  occur  in  the  construction  of  a  rule,  but  well-typed  roles  themselves  have  all  their  variables  bound  [8]. 

The  left-hand  side ,  or  antecedent ,  of  a  rule  is  a  finite  collection  of  parametric  message  predicates: 

Predicate  sequences:  Ihs  ::=  •  (Empty  predicate  sequence) 

Ihs,  l\l(i)  (Extension  with  a  network  predicate) 

Ihs,  L(e)  (Extension  with  a  role  state  predicate) 

Ihs,  MA(t)  (Extension  with  a  memory  predicate) 

Predicate  sequences  differ  from  states  mainly  by  the  limited  instantiation  of  role  state  predicates:  in  a  rule,  these  objects 
consist  of  a  role  state  predicate  variable  applied  to  as  many  elementary  terms  as  dictated  by  its  type  (this  is  enforced  by  the 
typing  rules  in  [8]).  Network  and  memory  predicates  will  in  general  contain  parametric  terms,  although  not  necessarily  raw 
variables  as  arguments.  An  example  involving  network  and  role  state  predicates  is  given  in  Appendix  A.  In  Section  5,  we 
rely  on  memory  predicates  to  model  the  intruder’s  knowledge.  Other  usages  can  be  found  in  [9], 

The  right-hand  side,  or  consequent,  of  a  rule  consists  of  a  predicate  sequence  possibly  prefixed  by  a  finite  string  of  fresh 
data  declarations  such  as  nonces  or,  in  some  applications,  short-term  keys.  We  rely  on  the  existential  quantification  symbol 
to  express  data  generation. 

Right-Eland  sides:  rhs  Ihs  (Sequence  of  message  predicates) 

:  r.  rhs  (Fresh  data  generation ) 

We  write  [t/x\rhs  for  the  capture-free  substitution  of  a  term  t  for  a  variable  x  in  the  consequent  rhs  [7].  We  adopt  a  similar 
notation  for  rules  and  predicate  sequences. 

2.5  Roles  and  Protocol  Theories 

Role  state  predicates  record  information  accessed  by  a  rule.  They  are  also  the  mechanism  by  which  a  rule  can  enable  the 
execution  of  another  rule  in  the  same  role.  Relying  on  a  fixed  protocol-wide  set  of  role  state  predicates  is  dangerous  since  it 
could  cause  unexpected  interferences  between  different  instances  of  a  role  executing  at  the  same  time.  Instead,  we  make  role 
state  predicates  local  to  a  role  by  requiring  that  fresh  names  be  used  each  time  a  new  instance  of  a  role  is  executed.  As  in  the 
case  of  rule  consequents,  we  achieve  this  effect  by  using  existential  quantifiers. 

Rule  collections:  p  ::=  ■  (Empty  role) 

3 L  :  t.  p  (Role  state  predicate  parameter  declaration ) 
r,  p  (Extension  with  a  rule) 

A  role  is  given  as  the  association  between  a  role  owner  A  and  a  collection  of  rules  p.  Some  roles,  such  as  those  imple¬ 
menting  a  server  or  an  intruder,  are  intrinsically  bound  to  a  few  specific  principals,  often  just  one.  We  call  them  anchored 
roles  and  denote  them  as  pA.  Here,  the  role  owner  A  is  an  actual  principal  name,  a  constant.  Other  roles  can  be  executed  by 
any  principal.  These  generic  roles  are  denoted  p'JA  where  the  implicitly  typed  universal  quantification  symbol  implies  that 
A  should  be  instantiated  to  a  principal  before  any  rule  in  p  is  executed.  We  require  that  the  owner  of  a  role  p  be  the  first 
argument  of  all  the  role  state  predicates  and  be  the  subscript  of  every  memory  predicate  in  p.  These  constraints  are  formally 
expressed  through  the  typing  and  DAS  policy  of  MSR. 

A  protocol  theory,  written  V,  is  a  finite  collection  of  roles  (see  Section  5  and  Appendix  A  for  concrete  examples): 

Protocol  theories:  V  ::=  •  (Empty  protocol  theory) 

V,  (Extension  with  a  generic  role) 

V,  pA  (Extension  with  an  anchored  role) 

It  should  be  observed  that  we  do  not  make  any  special  provision  for  the  intruder.  The  adversary  is  expressed  as  a  set  of  roles 
in  the  same  way  as  proper  protocols,  as  described  in  Section  5  for  the  standard  Dolev-Yao  intruder. 

2.6  Active  Roles 

Several  instances  of  a  given  role,  possibly  stopped  at  different  rules,  can  be  present  at  any  moment  during  execution.  We 
record  the  role  instances  currently  in  use,  the  point  at  which  each  is  stopped,  and  the  principal  who  is  executing  them  in  an 
active  role  set.  These  objects  are  finite  collections  of  active  roles,  i.e.  partially  instantiated  rule  collections,  each  labeled  with 
a  principal  name. 

Active  role  sets:  R  ::=  •  (Empty  active  role  set) 

R,  pA  ( Extension  with  an  instantiated  role) 
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The  notation  pA  is  reminiscent  of  anchored  roles.  Active  roles  are  actually  more  liberal  in  that  some  of  the  role  state  predicate 
symbols  as  well  as  their  arguments  may  be  instantiated.  Intuitively,  pA  results  from  instantiating  the  contents  of  some  role, 
with  A  is  its  elected  owner. 


3  Data  Access  Specification 

Well-typing  does  not  prevent  a  rule  from  looking  up  and  using  information  its  owner  should  not  have  access  to.  For 
example,  the  fact  that  principal  A  is  initiating  a  session  with  B  shall  not  allow  him/her  to  access  a  key  that  B  shares  with  a 
server.  Similarly,  A  should  not  be  able  to  access  the  memory  predicates  of  any  other  party.  The  following  role  incorporates 
several  violations  of  this  kind: 

(\/B:  principal.  /cB  :  pubK  B.  k'B :  privK  kss  :shK  B  S.  n:  nonce.  N(j{?7.]}-fcj3)  — >  N({n}fcfiS),  Ms(n))VA 

In  this  section,  we  will  use  the  typing  declarations  of  MSR  to  formalize  and  implement  these  and  other  requirements  by 
means  of  statically  checkable  data  access  specification  (DAS  for  short)  judgments.  We  shall  assume  that  all  the  expressions 
we  will  be  analyzing  are  well-typed.  We  will  start  with  the  presentation  of  DAS  for  macroscopic  objects  such  as  protocol 
theories  and  roles,  and  only  later  describe  how  it  is  enforced  on  their  components.  Therefore,  the  premises  of  inference 
rules  will  sometimes  mention  a  judgment  that  has  not  yet  been  defined.  We  mark  such  occurrences  by  enclosing  them  in  a 
gray  box  and  always  give  abundant  explanations.  We  ask  the  reader  to  ignore  the  Iboxed  text  that  follows  most  rules  in  this 
section.  We  will  interpret  it  in  Section  6. 

3.1  Protocol  Theories  and  Roles 


The  judgment  “E  IF  V”  expresses  the  fact  that  a  protocol  theory  V  realizes  correct  DAS  with  respect  to  a  signature  E.  It 
is  implemented  by  the  following  three  inference  rules  (in  structured  operational  semantics  style),  corresponding  to  the  three 
productions  in  the  syntax  of  a  protocol  theory.  The  right-hand  premise  of  rules  has.grole  and  has_arole  invoke  the  DAS 
judgment ‘T  F4  p”  for  rule  collections,  that  will  be  introduced  shortly. 


E  IF  V  (E,  A  :  principal)  IF A  p  E  IF  V  E  IFA  p 

- has_dot  - has_grole  - has_arole 

E  IF  •  E  IF  P,pyA  E  IF  V,pA 

The  central  rule,  which  applies  to  generic  roles,  pushes  the  declaration  for  the  role  owner  A  in  E,  with  the  effect  of  invoking 
its  right-hand  premise  with  a  typing  context.  Rule  has  arole  deals  with  anchored  roles;  since  we  are  working  under  the 
assumption  that  all  expressions  are  well-typed,  we  do  not  check  that  A  is  has  type  principal. 

Since  DAS  is  about  what  information  the  owner  of  a  role  is  entitled  to  access,  it  should  come  at  no  surprise  that  the 
judgments  that  operate  on  rule  collections  and  their  components  have  a  principal  as  a  distinguished  parameter.  We  first 
see  this  in  the  rule  collection  DAS  judgment  ‘T  F4  p\  where  A  is  the  owner  of  p:  It  is  implemented  by  the  following 
syntax-directed  rules: 


- oas_dot 

r  \bA  ■ 


□ 


(T,L  :  r)  IFA  p 

- oas_rsp  0 

r  IFA  3L  :  t.  p 


r  u-A  r  r  \\-A  p 

- oas_rule 

r  IFa  r,  p 


□ 


Rule  oas  rsp  collects  the  declaration  of  an  existentially  quantified  role  in  the  context  and  verifies  its  body.  We  rely  on  implicit 
a-conversion  to  rename  L  in  case  a  parameter  with  the  same  name  is  already  declared  in  T.  The  rightmost  inference  rule, 
oas_rule,  implements  the  situation  where  a  collection  starts  with  a  rule  r.  Its  left  premise  validates  r  itself  by  means  of  the 
DAS  judgment  for  rules, ‘T  F4  r” . 


The  judgment ‘T  F4  r”  expresses  DAS-validity  for  rules.  It  is  implemented  by  the  following  two  rules: 


T;  •  IFa  Ihs  >  •  ^  A  T;  A  IFA  rhs 
T  IF.  Ihs  — »  rhs 


uas_core 


□ 


(r,£  :  r)  IFa  r 
T  IF.  Vx  :  r.r 


-an  □ 


Intuitively,  the  judgment  in  the  left  premise  of  rule  uas_core,  ‘T;  •  IF4  Ihs  >  ■  tA-  A”,  collects  the  data,  t  say,  the  rule  owner 
A  is  given  in  the  left-hand  side  Ihs.  This  includes  network  messages  and  previously  gathered  information  stored  in  memory 
or  role  state  predicates.  This  judgment  also  produces  the  knowledge  context  A  (defined  shortly),  which  contains  information 
that  A  can  reasonably  deduce  from  t  and  later  use  in  the  right-hand  side.  Since  it  contains  information  about  which  key 
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belongs  to  whom,  etc.,  the  context  T  plays  an  important  role  in  deciding  what  can  legitimately  enter  A.  This  judgment  and 
its  realization  are  the  topic  of  Section  3.2.  Informally,  the  judgment  on  the  right  premise  of  this  rule,  ‘T ;  A  \\~A  rhs ”  uses 
the  knowledge  A  produced  by  analyzing  the  antecedent  to  verify  that  A  can  construct  all  the  messages  mentioned  in  the 
right-hand  side  rhs.  This  judgment  and  the  inference  rules  implementing  it  are  the  subject  of  Section  3.3. 

We  conclude  this  section  by  introducing  the  notion  of  knowledge  context,  often  simply  referred  to  as  knowledge.  These 
entities  collect  the  information  known  to  the  owner  of  a  rule  during  DAS-validation.  Knowledge  is  deduced  by  means 
of  simple  inferences  from  data  stored  in  role  state  or  memory  predicates,  and  messages  received  from  the  network.  The 
knowledge  context  of  a  rule  consists  of  atomic  constants  or  variables  only.  Active  role  sets  additionally  allow  ground  terms 
(obtained  by  instantiating  variables). 


Knowledge  contexts:  A 


(Empty  knowledge  context) 

A,  a  (Extension  with  atomic  knowledge) 

A,  x  (Extension  with  parametric  knowledge) 
A,  t  (Extension  with  ground  terms) 


We  will  ignore  the  last  production  until  Section  3.4,  where  DAS  for  active  roles  is  discussed.  It  is  convenient  to  view 
knowledge  contexts  as  multisets.  A  knowledge  context  A  is  said  to  be  compatible  with  a  signature  £  if  for  each  term  t  in  A, 
there  is  a  type  r  such  that  £  h  r  and  £  h  t :  r. 


3.2  Accessing  Information  in  the  Left-Hand  Side 


The  left-hand  side  of  a  rule  gathers  the  information  necessary  for  constructing  the  messages  transmitted  or  stored  in  the 
consequent.  The  information  in  the  left-hand  side  of  a  rule  r  consists  of  the  arguments  of  the  role  state  predicates  and  the  data 
embedded  in  the  messages  received  from  the  network  or  retrieved  from  memory  predicates.  We  will  now  take  an  informal 
look  at  each  of  these  sources: 

•  The  arguments  e  =  (ei, . . . ,  en)  of  a  role  state  predicate  L  represent  data  passed  to  a  rule  from  its  logical  predecessor. 
The  owner  of  r,  call  him/her  A,  knows  this  information  because  he/she  has  put  it  there.  These  elementary  symbols 
will  generally  stand  for  principal  names,  keys,  or  nonces,  but  variables  may  also  represent  complex  terms  whose  inner 
values  A  cannot  or  does  not  need  to  access  (e.g.  a  message  encrypted  with  a  key  he/she  does  not  know)  [8].  For 
example,  even  if  it  is  clear  from  the  protocol  at  hand  that  the  variable  e 3  can  only  be  substituted  with  a  term  of  the  form 
{  //}  /,.,  it  cannot  be  used  to  access  y,  even  if  e-  is  precisely  k.  (This  form  of  delayed  message  interpretation  can  easily 
be  realized  using  memory  predicates.) 

•  The  term  t  in  an  incoming  network  message  N  (t)  will  generally  consist  of  a  number  of  operators  applied  to  variables 
(in  rare  occasions  to  constants).  Some  of  the  associated  values  are  expected  to  match  previously  known  data  (e.g.  a 
nonce  coming  back  in  response  to  a  challenge),  and  will  be  represented  by  variables  listed  in  a  role  state  predicate. 
Others  will  be  unknown  (e.g.  a  nonce  generated  by  an  interlocutor)  and  shall  be  bound  to  previously  unused  variables. 
The  goal  of  DAS  is  to  make  sure  that  A  has  legitimate  rights  to  access  this  information. 

•  Finally,  A  can  retrieve  previously  stored  information  from  a  memory  predicate  M  i  (t).  As  for  network  messages, 

each  term  in  t  may  consist  of  a  series  of  constructors  applied  to  variables.  Again,  writing  an  argument  in  this  way 
means  accessing  the  subcomponents  corresponding  to  each  constant  or  variable,  with  the  option  of  using  them  in  the 
right-hand  side.  Observe  that  the  fact  that  A  generated  M^(i)  does  not  automatically  grant  him/her  access  to  the 
submessages  of  t.  For  example,  the  third  argument  t.3  may  have  the  form  ^  is  entitled  to  access  t  only  if  he/she 

is  in  possession  of  the  private  key  corresponding  to  k. 

In  this  section,  we  will  ultimately  devise  a  procedure  that  certifies  that  A  is  entitled  to  access  all  the  elementary  terms 
mentioned  in  the  antecedent  of  a  rule  r.  This  proceeds  in  two  phases:  first  we  collect  the  arguments  of  all  the  predicates  in 
the  left-hand  side  of  r,  and  then  break  the  composite  messages  gathered  in  this  way  into  their  elementary  components. 

The  judgment  ‘T;  A  K,  Ihs  >  i  >  A'”  collects  the  arguments  of  the  predicates  in  the  left-hand  side  of  a  rule.  Its 
meta-variables  are  interpreted  as  follows:  A  is  the  owner  of  the  rule  r  whose  left-hand  side  we  are  analyzing.  T  is  the  typing 
context  of  r.  The  predicate  sequence  Ihs  is  the  portion  of  the  antecedent  of  r  that  has  still  to  be  examined.  The  terms  t  are 
the  arguments  that  have  been  gathered  so  far  and  that  may  need  further  processing.  The  input  knowledge  A  lists  collected 
arguments  that  are  known  to  be  elementary.  Finally,  the  output  knowledge  A'  stands  for  the  elementary  information  that  will 
ultimately  be  extracted  from  r’s  left-hand  side.  It  is  convenient  to  interpret  this  judgment  operationally  as  a  partial  function 
that  given  A,  F,  Ihs,  t  and  A  computes  a  value  for  A'  if  the  DAS  policy  is  obeyed.  We  shall  interpret  t  as  a  multiset.  As 
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we  start  processing  the  antecedent  of  a  rule  in  rule  uas_core,  A  and  t  are  empty  (written  “•”)  as  no  argument  has  yet  been 
collected. 

Our  first  rule  describes  how  a  role  state  predicate  L(A,  e )  is  processed.  Remember  that,  by  definition,  L  is  a  parameter, 
its  first  argument  A  is  a  principal  name,  and  the  terms  (A,  e)  must  be  either  constants  or  variables.  Therefore,  each  object 
among  (A,  e)  is  an  elementary  piece  of  information.  We  can  therefore  merge  (A,  e)  into  the  current  input  knowledge  context 
A  and  use  the  resulting  knowledge  context  A'  to  analyze  the  remaining  predicates  Ihs.  We  have  the  following  rule,  which 
makes  use  of  the  merge  judgment  “A  >  e  >  A'”,  whose  simple  realization  is  given  in  Appendix  C. 

A  >  (A,e)  >  A'  T;  A'  lhA  Ihs  >  t'  >  A"  %  ^ 

las_rspn  0 

T;  A  lbA  (L(A,  e),  Ihs)  >  t'  »  A" 

We  next  turn  to  network  and  memory  predicates  in  the  antecedent  of  a  rule.  Since  the  messages  in  their  arguments  may 
not  be  elementary,  we  shall  include  them  in  the  list  of  unprocessed  arguments  t'  before  examining  the  remaining  predicates 
Ihs.  Only  memory  predicates  belonging  to  A  are  accepted. 

T;  A  lbA  Ihs  >  (t,  f )  >  A"  T;  A  lbA  Ihs  >  (t,  t')  >  A' 

-  las_net  |  INT  -  las_mem  jj 

T;  A  lbA  (N(f),  Ihs)  >  t'  »  A"  T;  A  lbA  (M A(t),  Ihs)  >  t'  »  A' 

Once  the  arguments  of  all  the  predicates  on  the  left-hand  side  of  the  rule  have  been  collected,  we  move  to  the  second  phase 
which  ascertains  that  the  uninterpreted  terms  t  satisfy  the  DAS  policy.  This  is  done  in  the  following  rule  by  invoking  the 
judgment ‘T;  A  lbA  t.  >>  A'”,  discussed  below. 


T;  A  lbA  t  »  A' 
T;  Alb A  •  >  f »  A' 


las_dot 


The  judgment  ‘T;  A  lbA  t  A'”,  used  in  rule  las  dot,  examines  possibly  composite  terms.  The  interpretation  of 
its  meta-variable  is  inherited  from  the  argument  collection  judgment  above.  Again,  this  judgment  can  be  seen  as  a  partial 
function  that  computes  a  value  for  A'  when  given  A,  T,  A  and  t.  It  should  be  observed  that  A  does  have  legitimate  access  to 
each  term  in  t:  we  want  to  verify  that  this  property  extends  to  their  subterms. 

Our  first  two  rules  deal  with  unchecked  elementary  messages  e.  There  are  two  possibilities:  either  e  is  known  and  therefore 
appears  in  the  current  input  knowledge,  or  it  must  be  looked  up  in  the  typing  context  T. 


T;  (A,  e)  lbA  f»  A' 
T;  (A,  e)  lhA  e,  A' 


tasjkni*'  DEL 


(T,e  :  r,r');  (A,e)  lbA  A' 
(r,e:r,r');A  lhA  e,f»  A' 


■  tas_ukn  Q 


The  rule  owner  A  can  access  the  cleartext  t  of  an  encrypted  message  {t.}k  (or  -j{i]}fc)  only  if  he/she  is  entitled  to  access  the 
decryption  key  corresponding  to  This  is  ascertained  by  the  left  premises  of  the  following  rules.  The  judgment  T;  A  b  , 
k  »  A'  (resp.  T;  A  P4  k  :$>  A')  verifies  that  A  can  access  k  (resp.  its  inverse)  and  if  necessary  updates  the  knowledge 
context  A  to  A'.  Once  the  key  has  been  resolved,  the  cleartext  t  is  put  back  in  the  pool  of  pending  messages,  which  is 
recursively  analyzed  in  the  rightmost  premise. 


T;  A  I bA  fc  »  A'  T;  A'  lbA  t,  F»  A'' 
T;  A  lbA  A" 


T;  A  IP.  fc»  A'  T;  A'  lbA  t,F»  A" 


tas_ske 

|SDC 


r;  a  IK 


ki 


t  >  A" 


tas_pke 
I  PDC  I 


Concatenated  messages  can  be  split  unconditionally  before  recursively  analyzing  their  submessages.  Once  all  possibly 
composite  terms  have  been  reduced  to  their  elementary  constituents  (and  have  been  shown  to  respect  the  DAS  policy),  we 
simply  return  the  accumulated  input  knowledge  context  as  the  output  knowledge. 


T;  A  lbA  ti,t2,t  »  A' 
T;  A  lbA  (f!f2),r>  A' 


tas_cnc  DCM 


T;  A  lbA  •  »  A 


-  tas_dot  p~| 


We  conclude  the  treatment  of  the  left-hand  side  of  a  rule  by  devising  a  method  to  establish  when  the  owner  of  a  rule 
can  decipher  (and  therefore  access)  a  message  encrypted  with  a  key  k.  Since  we  assumed  in  Section  2  to  have  two  kinds 
of  encryption  operations  (shared-key  and  public-key),  we  will  present  two  judgments  and  the  relative  rules.  It  should  be 


noted  that  richer  schemes,  e.g.  including  digital  signatures  or  a  more  refined  key  taxonomy,  would  need  to  define  additional 
judgments  and  to  provide  the  corresponding  DAS  rules. 

We  express  the  fact  that  the  owner  A  of  a  rule  can  access  the  cleartext  t  of  a  message  { /. } /.  encrypted  with  a  shared  key 
k  by  means  of  the  judgment  ‘T;  A  IPA  k  ^  A'”,  where  1,  A  and  A'  are  the  typing  context,  and  the  input  and  output 
knowledge  respectively.  Again,  A'  is  computed  from  the  other  entities  in  this  relation.  In  order  for  A  to  decrypt  { t }  /i: ,  he/she 
must  have  access  to  k  itself  since  we  are  in  a  symmetric -key  setting.  There  are  two  scenarios  to  analyze  in  order  to  decide 
this  judgment.  First,  A  may  know  for  example  if  it  was  previously  transmitted  in  the  clear.  Then,  k  can  be  found  in  the 
input  knowledge  context. 

-  kas_ss  |  DTJP  | 

r;  (A,fc)  IPA  k  >  (A,fc) 

The  second  scenario  involves  a  key  A  does  not  know  (yet)  about,  but  to  which  he/she  has  legitimate  access.  A  principal 
has  the  right  to  access  a  shared  key  only  if  this  key  was  intended  to  communicate  with  him/her: 

-  kas_sul  IS1 1  -  kas_su2  |  IS2 

(r,fc  :  shK  AB,T')-A  \PA  (A,fc)  (r,  k  :  shK  B  A,T');  A  IP*  k  »  (A,  k)  ’ 

Observe  that  the  relationship  between  the  key  owner  and  the  rule  owner  is  encoded  in  the  dependent  type  that  qualifies  the 
key  itself.  Since  k  was  unknown  to  A  but  is  being  accessed,  we  include  it  among  the  output  knowledge  of  these  rules. 

The  judgment ‘T;  A  IP,  k  A'”  expresses  the  similar  relation  concerning  public-key  encryption,  where  the  meaning 
of  the  meta-variables  is  as  for  symmetric  keys.  In  order  to  decipher  a  message  encrypted  with  a  public  key  /.;,  we  must  have 
access  to  the  corresponding  private  key,  call  it  k’ .  As  for  shared  keys,  the  first  place  where  to  look  is  the  current  knowledge 
context.  If  the  private  key  k!  of  some  principal  B  has  previously  been  encountered,  then  we  can  decipher  transmissions 
encoded  with  the  corresponding  public  key  k. 


-  kas_pus  |  DTJP  | 

(r,  k  :  pubK  B,  r',  k!  :  privK  k,  T");  (A,  k’)  IPA  k  >  (A,  k’) 

If  A  does  not  know  k1 ,  then  he/she  is  entitled  to  access  the  cleartext  of  the  encrypted  message  -{{/]}•/,,  only  if  he/she  owns  k: 

-  kas.puu  IPV,  DUP  | 

(T,  k  :  pubK  A,  F’ ,k’  :  privK  k,  T");  A  IPA  k  »  (A,  k’) 

3.3  Processing  Information  in  the  Right-Hand  Side 

The  right-hand  side  of  a  rule  is  where  messages  are  constructed,  either  to  be  emitted  over  the  public  network,  or  stored  for 
future  use.  However,  the  first  rule  of  an  initiator  role  will  generally  have  an  empty  left-hand  side,  and  yet  it  can  send  complex 
messages  in  its  consequent.  Therefore,  the  right-hand  side  of  a  rule  can  also  access  data  on  its  own,  information  that  is  not 
mentioned  in  its  antecedent.  This  can  happen  in  two  ways:  first  by  generating  fresh  data  (e.g.  nonces),  and  second  by  using 
information  that  is  “out  there”  (e.g.  the  name  of  an  interlocutor,  or  a  key  shared  with  him/her).  Both  alternatives  have  the 
potential  of  violating  the  DAS  policy  (e.g.  when  trying  to  access  the  private  key  of  a  third  party). 

DAS  on  the  right-hand  side  rhs  of  a  rule  r  is  expressed  by  the  judgment:  ‘T;  A  h4  rhs”,  where  A  is  the  owner  of 
r,  T  is  its  typing  context,  and  A  is  the  knowledge  gained  by  examining  its  antecedent,  it  is  implemented  by  rules  whose 
number  depends  on  the  intended  application  of  the  protocol  at  hand.  Given  a  consequent  of  the  form  “3a:  :  r.  rhs”.  It  is 
tempting  to  indiscriminately  add  x  to  the  current  knowledge  context  and  proceed  with  the  validation  of  rhs.  This  is  in  general 
inappropriate  since  it  would  allow  any  principal  to  construct  information  that  can  potentially  affect  the  rest  of  the  system.  In 
most  protocols,  nobody  should  be  allowed  to  create  new  principals.  Similarly,  only  key-distribution  protocols  should  enable 
a  principal  to  create  keys,  and  typically  only  short-term  keys.  On  the  other  hand,  principals  will  generally  be  allowed  to 
generate  nonces  and  atomic  messages  (e.g.  an  intruder  may  want  to  fake  a  credit  card  number).  These  considerations  produce 
a  family  of  rewrite  rules  that  differ  only  by  the  type  of  the  existential  declaration  they  consider.  In  all  cases,  we  recursively 
check  the  body  rhs  after  inserting  “x  :  r”  in  the  context  (for  appropriate  r’s)  and  adding  x  to  the  current  knowledge: 

(r,  x  :  nonce);  (A,  x)  \\-A  rhs  (T,  x  :  msg);  (A,  x)  \\~A  rhs  T;  A  Ihs 

- ras_nnc  -  ras_msg  - ras_ps 

T;A  11-4  3a;:  nonce,  rhs  |gnc|  T;A  II-4  3a::  msg.  rhs  I  GMSt  T;A  lbA  Ihs  □ 

We  must  emphasize  again  that  the  exact  set  of  rules  for  data  generation  depends  on  the  intended  functionalities  of  the  protocol. 
Rule  ras_ps  invokes  the  predicate  sequence  validation  judgment ‘T;  A  3-^4  Ihs”,  discussed  shortly,  to  verify  that  the  inner 
core  Ihs  of  the  rule’s  consequent  satisfies  DAS. 
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The  premises  of  rule  ras_ps  above  included  the  judgment  ‘T;  A  Ihs”  which  verifies  that  all  the  messages  in  the 
predicate  sequence  Ihs  can  be  constructed  in  the  current  rule.  It  is  implemented  by  the  following  rules.  When  Ihs  is  not 
empty,  we  rely  on  the  term  constructions  judgments  “A  t”  and  “A  t ”  that  will  be  explained  shortly. 


-  ras_dot 

r;  A  s->4  • 


del(A) 


T ;  A  <Hi  t 

r ;  A  S->4  Ihs 

dup(A),  trn 

T ;  A  N  (f ) ,  Ihs 


r;  a  ^  t 

r ;  A  S->A  Ihs 

-  me  mom 

r;AT->A  (A,  e)  r;A%  Ihs  , 

dup(A) 

dup(A) 

T :  A  ,  MJfl  Ihs 

ras_rsp^ 

r:  A  L(A.e).  Ihs 

Empty  predicate  sequences  are  always  valid.  Moreover,  a  principal  A  is  allowed  to  publish  any  information  he/she  can 
construct  on  the  public  network,  but  he/she  shall  be  able  to  update  only  his/her  own  role  state  and  memory  predicates. 

The  constructibility  of  a  term  t  in  the  right-hand  side  of  a  rule  is  expressed  by  the  judgment ‘T ;  A  S->A  t”.  Elementary 
information  appearing  in  a  rule  consequent  can  come  from  of  two  sources:  rule  cas_kn  handles  the  case  where  it  has  been 
collected  in  the  knowledge  context  while  validating  the  antecedent  and  fresh  data  declarations  of  a  rule.  This  can  also  be 
the  first  appearance  of  this  information  in  the  rule,  in  which  case  we  must  verify  that  the  role  owner  is  effectively  entitled  to 
access  it.  This  achieved  in  rule  cas  ukn  through  the  right-hand  side  access  judgment ‘T  e”,  discussed  below. 


-  casJkrr 

r;  (A,  e)  S-u  e 


del(A) 


r^e 

- cas_ukn 

r ;  A  s-u  e 


del(A) 


The  simple  rules  implementing  composite  terms  can  be  found  in  Appendix  C,  together  with  the  implementation  of  the 
judgment ‘T;  A  t”  that  allows  constructing  message  tuples  t  from  the  knowledge  A  at  hand. 

We  conclude  this  section  by  describing  the  judgment ‘T  S->A  e”  that  checks  that  a  rule  owner  A  has  legitimate  access  to 
elementary  data  e  that  appear  only  in  the  rule  consequent.  Its  implementation  depends  entirely  on  the  atomic  data  that  can 
be  part  of  a  message  and  therefore  on  the  types  that  have  been  defined  to  classify  them.  We  will  now  present  inference  rules 
relative  to  the  types  defined  in  Section  2,  but  it  should  be  clear  that  different  type  layouts  will  require  different  rules. 

Let  us  start  with  non-dependent  types.  We  should  clearly  be  able  to  access  any  principal  name: 


-  eas_pr  |  IPR  | 

(r,e  :  principal,  T')  S-»A  e 

The  remaining  simple  types  are  nonce  and  msg.  Were  we  to  have  a  rule  similar  to  eas  pr  for  nonces  would  allow  A  to  access 
any  nonce  in  the  system,  including  nonces  that  he/she  has  not  generated.  This  is  clearly  undesirable.  The  only  nonces  A  is 
entitled  to  access  are  the  ones  he/she  has  created  and  the  ones  he/she  has  retrieved  in  received  messages  or  as  previously  stored 
data.  In  all  these  cases,  these  nonces  are  included  in  some  knowledge  context.  A  similar  argument  applies  to  elementary 
objects  of  type  msg:  a  rule  akin  to  eas_pr  would  give  A  access  to  any  message  that  can  be  constructed  in  the  system,  when 
invoked  with  a  variable.  This  is  particularly  undesirable  since  msg  is  a  supersort  of  all  our  types  (see  Section  2.3). 

Next,  we  consider  keys:  A  should  have  free  access  to  all  of  his/her  shared  keys,  but  not  to  others;  similarly,  A  has 
legitimate  access  to  his/her  private  keys,  and  to  the  public  keys  of  any  principal. 


-  eas_sl  |  IS1 1  - eas_s2  |  IS2  | 

(r,e  :  shK  AB,T')  ‘Ht  e  (r,e:shKBT,r')%  e 

- eas_pp  |  IP V  |  - eas_p  |  IPB  | 

(r,  e  :  privK  k,  V' ,  k  :  pubK  A,  T")  S->A  e  (r,  e  :  pubK  B ,  T')  S->A  e 

It  should  be  observed  that  protocols  that  make  use  of  a  key  distribution  center  should  not  rely  on  these  rules.  These  kinds  of 
protocols  require  a  language  and  type  layout  that  is  more  elaborate  than  the  one  in  our  running  example. 


3.4  Active  Roles 


In  Section  2.6  we  defined  an  active  role  as  a  role  suffix  whose  free  variables  have  been  instantiated  to  ground  terms.  They 
correspond  to  roles  in  the  midst  of  execution.  Active  roles  should  clearly  be  subject  to  the  same  access  constraints  as  protocol 
theories.  They  are  handled  by  allowing  ground  terms  anywhere  variables  can  appear  in  a  role,  and  by  treating  them  in  the 
same  way.  Formally,  for  every  of  the  above  rules  that  look  up  or  store  (elementary)  information  in  an  active  role  set,  we 
introduce  a  variant  that  performs  the  same  operation  on  a  ground  term.  The  affected  rules  are  marked  with  the  symbol  (j  in  the 
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above  discussion  and  in  Appendix  C.  Furthermore,  since  execution  may  instantiate  a  role  state  predicate  parameter  L  with  a 
constant  L/,  we  need  additional  variants  of  rules  las  rsp  and  ras  rsp. 

The  judgment  “E  IF  R”  expresses  the  fact  that  an  active  role  set  R  satisfies  our  DAS  policy  in  signature  E.  It  is 
implemented  by  the  following  two  simple  rules: 


-  aas_dot 

E  IF  • 


□ 


E  IF  R  E  IF A  p 

- aas_ext 

E  IF  RlPA 


pA  if  A  +  \ 


3.5  Decidability  of  DAS 


All  the  judgments  presented  in  this  section  have  decidable  implementations.  Furthermore,  the  ones  to  which  we  have 
ascribed  a  functional  behavior  implement  computable  relations.  For  space  reasons,  we  only  give  a  sketch  of  the  argument 
underlying  this  result  and  a  condensed  statement  relative  to  protocol  theories  and  active  role  sets  only.  A  detailed  proof  of 
this  statement  for  each  of  these  judgments  can  be  found  in  [6], 

Property  3.1  Given  a  signature  E,  a  protocol  theory  V  and  an  active  role  set  R,  it  is  decidable  whether  the  judgments 
E  IF  V  and  E  IF  R  hold. 

Proof:  All  DAS  rules  are  syntax-directed  and,  with  the  exception  of  uas  core,  las  rsp  (and  variants),  fas  ske  and  tas  pke, 
none  contains  meta-variables  in  its  premises  that  are  not  also  mentioned  in  its  conclusion.  The  leftmost  premise  of  each  of 
these  rules  is  a  left-hand  side  judgment  J  that  produces  an  output  knowledge  context  A'  (the  one  meta-variable  that  does  not 
appear  in  their  conclusion).  Thus,  we  reduce  our  decidability  result  to  proving  that  there  are  only  finitely  many  such  A'  for 
which  J  is  derivable,  assuming  all  other  parameters  fixed.  A  close  inspection  of  the  DAS  rules  reveals  a  number  of  pairs  of 
rules  (for  example  tas  ukn  and  tas  kn)  that  may  both  apply  in  certain  situations,  and  therefore  have  J  succeed  with  two 
output  knowledge  contexts.  In  the  worst  case,  the  number  of  output  knowledge  contexts  is  exponential  (but  finite)  in  the 
number  of  symbols  appearing  in  the  other  parts  of  ,J.  □ 

When  validating  rules,  alternative  output  knowledge  contexts  are  identical  up  to  the  duplication  of  data.  On  the  basis  of  this 
observation,  we  claim  that  DAS  can  be  implemented  with  a  complexity  linear  in  the  number  of  elementary  terms  in  a  rule. 
This  argument  extends  to  active  role  sets  by  prioritizing  rules  that  look  information  up  in  the  current  knowledge  context  ( e.g . 
tas_kn). 


4  Execution  Model 


Execution  is  concerned  with  the  use  of  a  protocol  theory  to  move  from  a  situation  described  by  a  state  S  to  another 
situation  modeled  by  a  state  S'.  Referring  to  the  situation  that  the  execution  of  a  protocol  has  reached  by  means  of  a  state  is 
an  oversimplification.  Indeed,  execution  operates  on  configurations  [5]  §  consisting  of  a  state  S,  an  active  role  set  R  and  a 
signature  E:  R  records  the  roles  that  can  be  used  in  order  to  continue  the  execution,  at  which  point  they  were  stopped,  and 
how  they  were  instantiated,  while  E  is  needed  to  ensure  that  variable  instantiation  is  well-typed.  No  element  in  a  configuration 
contains  free  variables.  Configurations  will  be  indicated  with  the  letter  C. 

Given  a  protocol  V,  we  describe  the  fact  that  execution  transforms  a  configuration  C  into  C'  in  one  step  by  means  of  the 
judgment  “ V  >  C  — >  C'” .  The  next  two  rules  specify  how  to  extend  the  current  active  role  set  R  with  a  role  from  V . 

E  F  A  :  principal 

-  ex_arole  - ox  grok: 

(V,  PA)  >  [5]  *  — >  [5]  (V,  p^A)  >  [5]  *  — ►  [5]  £’([a/awA 

Anchored  roles  are  simply  copied  to  the  current  active  role  sets  since  their  syntax  meets  the  requirements  for  active  roles. 
We  instead  make  a  generic  role  available  for  execution  in  rule  ex  grole  by  assigning  it  an  owner.  The  typing  judgment  in  its 
premise  makes  sme  that  A  is  defined  as  a  principal  name. 

Once  a  role  has  been  activated,  chances  are  that  it  contains  role  state  predicate  parameter  declarations  that  require  to  be 
instantiated  with  actual  constants  before  any  of  the  embedded  rules  can  be  applied.  In  rule  ex_rsp,  L/  shall  be  a  new  symbol 
that  appears  nowhere  in  the  current  configuration  (in  particular  it  should  not  occur  in  E). 

E  F  t  :  t 

-  ex_rsp  - ex_all 

V>  A([L,/L]p)A  v>  [5]^((Vx:r.r),p)A  - +  [g]  fl,(([t/*]r-),p)A 
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Rule  ex_all  instantiates  the  universal  variables  that  may  appear  in  a  rule.  The  attentive  reader  may  be  concerned  by  the  fact 
that  the  construction  of  the  instantiating  term  t  is  not  guided  by  the  contents  of  the  state  S.  This  is  a  legitimate  observation: 
the  rule  above  provides  an  idealized  model  of  the  execution  rather  than  the  basis  for  the  implementation  of  an  actual  simulator. 
An  operational  model  suited  for  implementation  is  the  subject  of  current  research.  It  should  also  be  observed  that  the  premise 
of  ex_all  describes  A’s  acceptance  of  t  as  a  term  of  type  r.  How  this  happens  is  kept  abstract,  but  it  should  correspond  to 
some  lower  level  mechanism  to  adequately  express  the  protocol  at  hand. 

We  now  consider  execution  steps  resulting  from  the  application  of  a  fully  instantiated  rule  ( Ihs  — >  rhs )  from  the  current 
active  role  set  R.  The  antecedent  Ihs  must  be  ground  and  therefore  it  has  the  structure  of  a  legal  state.  This  rules  identifies 
Uis  in  the  current  state  and  replaces  it  with  a  substate  Ihs'  derived  from  the  consequent  rhs  by  instantiating  its  existential 
variables  with  fresh  constants  of  the  appropriate  type.  This  latter  operation  is  performed  in  the  premise  of  this  rule  by  the 
right-hand  side  instantiation  judgment  “(rhs)z  >>  ( lhs')-£> ”,  whose  implementation  is  given  in  Appendix  C. 

(rhs)-E  »  (Ihs')s' 

-  ex_core 

V>  [S,lhs]*’aihs^rhs)’p)k  — »  [S,  Ihs']  £;(p)A 

Security  protocols  often  allow  various  forms  of  branching.  In  a  protocol  theory,  the  control  structure  is  mostly  realized  by 
the  role  state  predicates  appearing  in  a  role.  Branching  can  indeed  be  modeled  by  having  two  rules  share  the  same  role  state 
predicate  parameter  in  their  left-hand  side.  Roles,  on  the  other  hand,  are  defined  as  a  linear  collection  of  rules.  Therefore, 
in  order  to  access  alternative  role  continuations,  we  may  need  to  skip  a  rule,  i.e.  discard  it  and  continue  with  the  rest  of  the 
specification. 


[5]fl,(P)A 


ex_skp 


v> 


[s]n^ 


V>  [5] 


«,(-)A 

E 


- ex_dot 

[s\i 


Rule  ex  dot  does  some  housekeeping  by  throwing  away  active  roles  that  have  been  completely  executed. 

The  judgment  “V  >  C  — >*  C'”  allow  chaining  atomic  transitions  into  multi-step  firings.  It  is  defined  in  Appendix  C  as 
the  reflexive  and  transitive  closure  of  the  above  one-step  relation.  A  parallel  version  of  this  judgment  has  been  defined  in  [7], 
Moreover,  we  have  proved  in  [8]  that  well-typing  is  preserved  by  execution,  i.e.  that  when  starting  from  well-typed  objects 
firing  will  always  produce  well-typed  entities  (a  detailed  proof  can  be  found  in  [6]). 

A  similar  result  applies  to  DAS.  Indeed,  the  DAS  Preservation  Theorem  below  states  that,  under  reasonable  typing 
assumptions,  no  execution  sequence  can  take  a  configuration  that  satisfies  the  DAS  policy  to  a  situation  that  violates  it.  In 
particular,  instantiating  variables  cannot  invalidate  DAS. 


Theorem  4.1  (DAS  Preservation) 

Let  V  be  a  protocol  theory,  E  and  S'  signatures,  R  and  R'  active  role  sets,  and  S  and  S'  states  such  that  I-  E,  E  h  V, 
Eh  R,  E  lh  V  and  E  lh  R  If 

[s]g  — *  [s']g;, 

then  the  judgments  E;  lh  V  and  S'  lh  R'  are  derivable. 


Proof:  The  proof  proceeds  by  induction  on  a  derivation  of  the  given  execution  judgment.  Rules  cx  rsp  and  ex  core  rely 
on  a  Weakening  Lemma  that  allows  extending  the  signature  of  an  DAS  judgment  without  affecting  its  derivability.  Rules 
ex_grole  and  ex_all  make  use  of  Substitution  Lemma  that  states  that  DAS  is  preserved  under  substitution,  assuming  some 
simple  preconditions  are  met.  □ 


Because  of  its  passive  role,  the  state  S  is  not  required  to  be  well  typed  for  this  result  to  hold,  although  applications  will 
generally  operate  on  well-typed  states.  This  theorem  and  the  fact  that  the  execution  rules  do  not  depend  on  any  DAS  judgment 
makes  DAS  verification  a  purely  static  check. 


5  The  Dolev-Yao  Intruder 


The  Dolev-Yao  abstraction  [15,  21]  assumes  that  elementary  data  such  as  principal  names,  keys  and  nonces  are  atomic 
symbols  rather  than  the  bit-strings  implemented  in  practice.  Furthermore,  it  views  the  operations  needed  to  assemble  mes¬ 
sages,  i.e.  concatenation  and  encryption,  as  pure  constructors  in  an  initial  algebra.  Therefore,  for  example,  a  term  of  the  form 
{f}fc  cannot  be  mistaken  for  a  concatenation  (t ±  t?),  and  {t.}k  =  { t '}*/  if  and  only  if  t  =  if  and  k  =  k! .  This  also  means  that 


12 


the  Dolev-Yao  model  abstracts  away  the  details  of  the  cryptographic  algorithms  in  use,  reducing  in  this  way  encryption  and 
decryption  to  atomic  operations.  Indeed,  it  is  often  said  to  adopt  a  black  box  view  on  cryptography. 

The  atomicity  and  initiality  of  the  Dolev-Yao  abstraction  limits  considerably  the  attacks  that  can  be  mounted  against  a 
protocol.  In  particular,  its  idealized  encryption  model  makes  it  immune  to  any  form  of  crypto-analysis:  keys  cannot  be 
exhaustively  searched,  piecewise  inferred  from  observed  traffic,  or  guessed  in  any  other  manner.  An  encrypted  message  can 
be  deciphered  only  when  in  possession  of  the  appropriate  key.  The  symbolic  nature  of  this  abstraction  allows  then  to  very 
precisely  circumscribe  the  operations  an  intruder  has  at  his  disposal  to  attack  a  protocol.  All  together,  they  define  what  has 
become  to  be  known  as  the  Dolev-Yao  intruder.  This  attacker  can  do  any  combination  of  the  following  eight  operations: 


1 .  Intercept  and  learn  messages. 

3.  Decompose  concatenated  messages  he  has  learned. 
5.  Decipher  encrypted  messages  if  he  knows  the  keys. 
7.  Access  public  information. 


2.  Transmit  known  messages. 

4.  Concatenate  known  messages. 

6.  Encrypt  known  messages  with  known  keys. 
8.  Generate  fresh  data. 


MSR,  like  most  current  systems  geared  toward  specifying  security  protocol,  is  an  instance  of  the  the  Dolev-Yao  abstraction. 
Elementary  data  are  indeed  atomic,  messages  are  constructed  by  applying  symbolic  operators,  and  the  criterion  for  identifying 
terms  is  plain  syntactic  equality.  We  will  now  give  a  specification  of  the  Dolev-Yao  intruder  in  MSR. 


Let  I  be  the  elected  intruder.  We  represent  the  knowledge  I  has  at  his  disposal  to  mount  an  attack  in  a  distributed  fashion 
as  a  collection  of  memory  predicates  of  the  form  /(f)  for  all  known  terms  f  (for  conciseness,  the  subscript  “|”  of  the  correct 
form  /|(f)  is  kept  implicit).  Thus,  the  declarations  “I  :  principal”  and  “/  :  principal  x  msg”  constitute  the  standard  Dolev-Yao 
intruder  signature,  that  we  denote  SDy.  We  express  each  of  the  Dolev-Yao  intruder’s  capabilities  as  one  or  more  one -rule 
roles  anchored  at  I.  We  give  them  a  name  (written  in  bold  to  its  left)  that  will  be  referred  to  in  Section  6.  We  also  organize 
rule  constituents  in  columns  for  legibility.  These  roles  constitute  the  standard  Dolev-Yao  intruder  theory  that  we  denote  V nY  ■ 
Items  (1)  and  (2)  of  the  description  of  the  Dolev-Yao  intruder  are  specified  by  rules  INT  and  TRN  below,  respectively. 
The  former  captures  a  network  message  N(f)  and  stores  its  contents  in  the  intruder’s  memory  predicate.  Observe  that  the 
execution  semantics  of  MSR  implies  that  N(f)  is  removed  from  the  current  state  and  therefore  this  message  is  not  available 
any  more  to  the  principal  it  was  supposed  to  reach.  Rule  TRN  emits  a  memorized  message  out  in  the  public  network. 

INT:  (Vf  :  msg.  N(t)  — >  /(f))1  TRN:  (Vf  :  msg.  /(f)  — »  N (f)) 1 


From  now  on,  we  will  only  deal  with  the  memory  predicate  /(_),  which  acts  as  a  workshop  where  I  can  dismantle  inter¬ 
cepted  communications  and  counterfeit  messages.  Concatenated  messages  can  be  taken  apart  and  constructed  at  will: 


DCM: 


^Vfi, f2  :  msg. 


/(f l  £2) 


CMP: 


Vf  1 , f2  :  rnsg. 


/(*  1) 
/(*2) 


I 


Items  (5)  and  (6)  of  the  above  specification  state  that  I  must  know  the  appropriate  decryption  keys  in  order  to  access  the 
contents  of  an  encrypted  message.  Dually,  he  must  be  in  possess  of  the  correct  key  in  order  to  perform  an  encryption. 


(VA,  B  :  principal. 
Vfc  :  shK  A  B. 

Vf  :  msg. 


Kith) 

l(k) 


(VA,  B  :  principal. 
Vfc  :  shK  A  B. 

Vf  :  msg. 


/(f) 

/(*) 


1 


/VA  :  principal. 

Vfc  :  pubK  A.  /({{f|fc) 
Vfc'  :  privK  k.  l(k') 
\Vf  :  msg. 


I(t)j 


(VA  :  principal. 
V/c  :  pubK  A. 
Vf  :  msg. 


/(f) 

l(k) 


/(MO 


We  now  tackle  the  often  overlooked  item  (7)  of  the  Dolev-Yao  intruder  specification:  the  ability  to  access  public  informa¬ 
tion.  The  intruder  should  clearly  be  entitled  to  look  up  the  name  and  public  keys  of  principals,  but  any  attempted  access  to 
more  sensitive  information  such  as  private  keys  should  be  forbidden.  Our  DAS  policy  already  enforces  this  kind  of  require¬ 
ments.  Therefore,  we  will  express  the  capabilities  of  the  intruder  with  respect  to  public  information  access  by  means  of  the 
strongest  rules  that  satisfy  DAS. 


ISl: 


VA  :  principal. 
V/c  :  shK  I  A. 


VA  :  principal. 
V/c  :  pubK  A. 


IPR:  (VA  :  principal. 

/(*)) 

/(A)) 


1(A))' 

A/A  :  principal. 
[yk  :  shK  Al. 

A/fc  :  pubK  I. 
\\/kr  :  privK  k. 


1 


1 
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The  last  item  of  the  specification  of  the  Dolev-Yao  intruder  hints  at  the  fact  that  he  should  be  able  to  create  fresh  data.  We 
must  again  be  very  careful  when  implementing  this  requirement:  in  most  scenarios,  it  is  inappropriate  for  I  to  generate  keys 
or  to  create  new  principals.  As  for  the  DAS  rules,  nonces  and  atomic  messages  are  however  risk-frees. 


GNC:  ( 


3 n  :  nonce. 


/(n))' 


GMS:  ( 


3 to  :  msg. 


/(H)' 


Observe  that  the  rationale  behind  these  two  rules,  although  reasonable,  may  conflict  with  idiosyncrasies  of  individual  proto¬ 
cols.  For  example,  the  full  version  of  the  Needham-Schroeder  public -key  authentication  protocol  presented  in  [9]  is  accurately 
validated  only  in  the  presence  of  an  intruder  who  can  create  public  keys. 

Last,  VDY  contains  the  following  two  administrative  rules  that  allow  the  Dolev-Yao  intruder  to  forget  information  and  to 
duplicate  (and  therefore  reuse)  fabricated  data,  respectively. 


DEL:  (Vi  :  msg.  /(f) 


DUP: 


^Vi  :  msg. 


I(t) 


i 


It  is  easy  to  verify  that  the  above  MSR  formalization  of  the  Dolev-Yao  intruder  is  well-typed  and  satisfies  DAS: 


Property  5.1  The  judgments  h  SDY,  EDy  h  VDY  and  SDy  lb  VDY  are  derivable. 

The  validation  of  the  judgment  “E DY  lb  VDY”  makes  use  of  all  the  DAS  rules  in  Section  3,  except  the  ones  dealing  with 
role  state  predicates. 

A  few  aspects  of  this  encoding  deserve  to  be  emphasized:  first,  this  specification  lies  completely  within  MSR  and  can 
therefore  be  adapted,  were  the  protocol  at  hand  to  require  it.  This  differentiates  MSR  from  most  other  formalisms  which 
either  rely  on  a  fixed  intruder,  or  express  it  in  a  language  distinct  from  regular  protocols.  Second,  typing  allows  a  very  precise 
characterization  of  what  the  intruder’s  capabilities  actually  are,  especially  as  far  as  access  to  public  information  and  fresh 
data  generation  are  concerned.  Third,  VDY  can  be  automatically  generated  from  DAS  rules  of  the  given  term  language  [10]. 


6  The  Most  Powerful  Symbolic  Attacker 


The  Dolev-Yao  intruder  is  by  no  means  the  only  way  to  specify  a  protocol  adversary.  Indeed,  MSR  allows  writing  attacker 
theories  of  much  greater  complexity  by  using  multi-rule  roles,  branching,  long  predicate  sequences,  diversified  memory 
predicates,  and  deep  pattern-matching.  It  is  however  commonly  believed  that  any  attack  mounted  by  such  an  attacker  can 
be  uncovered  by  using  the  Dolev-Yao  intruder.  The  assumption  that  the  Dolev-Yao  intruder  subsumes  any  other  symbolic 
adversary  (i.e.  that  plays  by  the  rules  of  the  Dolev-Yao  abstraction)  is  built  into  the  most  successful  security  protocol  verifica¬ 
tion  systems  [4,  14,  18,  20,  22,  24,  25],  To  our  knowledge  and  from  discussions  with  several  security  experts,  it  appears  that 
this  strongly  held  belief  has  never  been  proved.  This  is  worrisome  considering  the  seldom-acknowledged  subtleties  that  our 
formalization  of  the  Dolev-Yao  intruder  has  exposed  in  Section  5.  Our  precise  definition  of  DAS  and  the  fact  that  an  attacker 
is  specified  within  MSR  as  any  other  protocol  fragment  give  us  the  means  to  phrase  that  question  and  to  formally  prove  that 
it  has  a  positive  answer.  We  dedicate  this  section  to  this  task. 

Again,  let  I  be  the  intruder  (we  will  consider  situations  involving  multiple  intruders  at  the  end  of  this  section).  Assume 
that  we  are  given  a  derivation  of  a  generic  well-typed  and  DAS-valid  execution  judgment  V>  [S']  — >*  [S"]  w  ■  Clearly, 

V,  R  and  R'  can  mention  arbitrary  (active)  roles  anchored  on  the  intruder.  Similarly,  S  and  S'  can  contain  role  state  and 
memory  predicates  belonging  to  I.  We  will  show  that  we  can  construct  an  encoding  r  for  the  entities  appearing  in  that 
judgment  such  that:  1)  rVn,  rRn  and  rRn  do  not  mention  any  intruder  specification  besides  VDY\  2)  rS'n  and  rS',_l 
do  not  contain  any  role  state  predicate  for  I  nor  any  intruder  memory  predicate  except  at  most  /(_);  and  3)  the  judgment 
rV^,VDY  o  [rSn]  r£n  — >*  [S'i]  ^  is  derivable. 

The  encoding  rV n  of  a  protocol  theory  V  implements  the  idea  that  every  role  anchored  on  the  intruder  can  be  emulated 
by  means  of  VDY.  Therefore,  we  simply  filter  out  every  component  of  the  form  (p)  : 


r.n 

r 


V,  (p)VAn 

> 

r 

P. 

L 

II 

r,  ( p H 

< 

3 

r  r 
^  fX. 

L  L 

II 

if  A  ^  I 
otherwise 

The  Dolev-Yao  intruder  model  does  not  refer  to  any  role  state  or  memory  predicate  beside  /(_).  Whenever  one  of  these 
objects  appears  in  a  state  S ,  the  encoding  r,S'n  will  account  for  it  by  including  one  instance  of  the  Dolev-Yao  intruder  memory 
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predicate  /(_)  for  each  of  its  arguments,  as  specified  by  the  following  definition: 


r,~\  —  . 

rs,N(ty  =  r 

'sr>,  N(t) 

rs,  MaC ty  =  | 

frcn  Ff~\ 

[rS^,  M A(f) 

if  A=  1 

otherwise 

where 

t^ 

L 

II  II 

r  - 

L*  L 

i _ i 

rS,  L,(A, f)n  =  j 

r  rs~i,  rA,rn 
L,(A,r> 

if  A  =  1 

otherwise 

The  encoding  of  a  signature  E  is  obtained  by  including  any  part  of  the  Dolev-Yao  intruder  signature  EDy  that  may  be 
missing  in  E.  More  precisely,  rEn  is  defined  as  EDy-  U  (E  \  (E  fl  SDy)).  The  target  signature  S'  of  an  execution  judgment 
may  contain  role  state  predicate  symbol  declarations  introduced  by  the  execution  of  a  (non  Dolev-Yao)  attacker  role.  We 
shall  remove  them  from  the  translation,  as  indicated  in  the  statement  of  Theorem  6.3. 

While  the  above  entities  can  be  given  an  encoding  based  exclusively  on  their  structure,  this  approach  does  not  work 
smoothly  for  active  role  sets.  Attacker  rules  are  problematic:  clearly,  we  want  to  map  their  operations  to  Dolev-Yao  intruder 
roles,  but  the  direct  realization  of  this  idea  requires  a  wider  context  than  what  offered  by  a  simply-minded  recursive  definition. 

For  example,  upon  encountering  a  term  {t}k  in  an  incoming  message,  we  may  or  may  not  need  to  use  one  of  the  shared-key 
roles  IS1  and  IS2  to  look  up  k.  Furthermore,  it  is  not  clear  whether  a  copy  of  k  is  needed  in  other  parts  of  the  rule. 

If  we  only  consider  entities  that  satisfy  the  typing  and  DAS  restrictions,  we  can  circumvent  this  difficulty  by  basing  the 
encoding  of  an  active  role  set  R  on  a  derivation  A  of  the  DAS  judgment  E  IF  R,  for  a  given  signature  E.  Indeed,  A  would 
specify  how  the  key  k  in  the  above  example  is  accessed,  and  indirectly  how  many  times  it  is  needed  in  the  rule  it  appears  in. 

The  translation  of  each  DAS  rule  is  given  in  Section  3  as  a  Iboxedl  annotation  next  to  the  name  of  each  rule.  These  annotations 
are  either  1)  a  non-intruder  active  role  pA,  2)  the  name  of  a  role  in  VDY,  3)  if  no  role  needs  to  be  mapped  to  this  rule,  or 
finally  4)  the  abbreviations  DEL(A)  and  DUP(A)  which  stand  for  as  many  copies  of  role  DEL  (resp.  DUP)  as  there  are 
elements  in  the  knowledge  context  A  appearing  in  this  rule  (see  [6]  for  a  formal  definition). 

Given  a  derivation  A  of  E  IF  R,  we  construct  rAn  by  collecting  the  active  roles  corresponding  to  the  annotation  of  each 
rule  that  appears  in  A.  We  define  rR~1  as  r A~ .  This  definition  entails  that  the  encoding  of  any  active  role  anchored  on  I 
consists  exclusively  of  Dolev-Yao  roles  from  VDy  ■ 

As  an  example,  consider  an  active  role  consisting  of  the  partially  instantiated  rule  p1  =  (Vns  :  nonce.  L(l,  B,  (<b,  n  i  ) ,  N({[n|7T,B§ki) 
N  ( {{ a  /j }}  kB ) ) 1  j  taken  from  the  specification  of  the  Needham-Schroeder  protocol  in  Appendix  A.  This  rule  is  being  executed 
by  the  intruder.  Assuming  an  appropriate  signature  E,  we  have  the  following  derivation  for  p1,  where  we  have  reported  the 
non-empty  boxed  annotations. 


r ;  A  \PA  k,  >  (A,  k[)[ 


IP  V,  DUP 


r-,A',ng  IFa  •  3>  (A \nB) 

-  tas_ukn 

IF  A'  lhA  nB  >  A" 

-  tas.kn 

T;  A'  IFa  n,,ns  »  A"  pel  I 

-  tas.cnc 

T;A'  II— a  (n|ns)>A"  PCMI 


r;  A  I  Fa  «n,nBJk|  »  A" 


tas.pke  fPDC] 


T;  A"  S->a  n  pi  del6 


IF  A  I  Fa  N(Sn,nsJk|)>->A" 


las.net ,  las_dot 


T;  A"  kB  I  del6  | 

-  cas.pke 


IF  A"  <Ht 


DUP  ,  PEC 


IF  -  I  Fa  L(l,B,kB,nl),N(«nlns}k|)>->A" 


•  ras_net,ras_dot 


IFA"Va  N(fnsJkB) 


I  DUP°  ,  TRN,  DEL 


(E,ns:  nonce)  I  Fa  L(l,  B,  kB,  n,).  N(|n,  nB}k|)  ->  N({ns  Jke) 


uas.core 


E  IFa  VnB  :  nonce.  L(l,  B,  kB,  n, ),  N(f  n,  nB  Jk|)  ->  N(fns  Jke) 


s.ext ,  aas.dot .  uas_all 


where  T  =  (E,  hb  :  nonce),  A  =  (I,  B,  kg,  n|).  A'  =  (A,  k[)  and  A"  =  (A,  ns)-  The  translation  of  p1  is  the  active  role  given 
by  collecting  the  boxed  Dolev-Yao  intruder  actions:  rpln  =int,pdc,ipv,dcm,trn,pec,dup13,del19.  Observe  that,  the 
first  six  rules  correspond  to  the  operations  needed  to  dismantle  the  message  N(j{ni  ns])^)  and  construct  N(-{{nB]}-kB)-  Most 
of  the  duplication  and  deletion  rules  elide  each  other;  the  remaining  six  are  used  to  get  rid  of  the  knowledge  A"  since  it  is 
not  memorized  in  any  way  in  the  consequent  of  p1 . 

The  family  of  translations  r_n  for  our  various  objects  preserves  any  entity  not  pertaining  directly  to  the  intruder.  In 
particular,  network  messages,  memory  and  role  state  predicates  of  other  principals,  and  the  roles  that  transform  them  are 
unaffected.  It  is  easy  to  prove  that  r_n  preserves  typing  and  DAS  [6]. 
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Lemma  6.1  Let  E  be  a  signature,  V  a  protocol  theory,  S  a  state,  and  R  an  active  role  set. 

If  b  E,  Sh?,  ELS,  Eh  R,  E  Ih  V  and  E  Ih  R, 

then  h  rEn,  rEn  h  rVn,  rEn  h  rSn,  rE“l  h  rRn,  rEn  Ih  rVn  and  rEn  Ih  riT. 

Theorem  6.3  below  states  that  the  Dolev-Yao  intruder  is  the  most  powerful  attacker,  in  the  sense  that  it  can  emulate  the 
deeds  of  any  other  attacker.  A  proof  of  this  result  relies  on  a  number  of  lemmas  that  describe  how  the  translation  of  derivations 
for  each  of  the  DAS  judgments  from  Section  3  is  mapped  to  an  execution  sequence.  Due  to  space  limitations,  we  shall  refer 
the  interested  reader  to  [6]  for  a  presentation  of  these  auxiliary  results  and  of  their  proofs.  We  give  a  flavor  of  the  elegant  proof 
technique  underlying  our  Theorem  6.3  by  displaying  the  statement  of  one  of  these  lemmas,  which  shows  how  the  Dolev-Yao 
intruder  can  emulate  the  access  to  the  information  appearing  in  terms  in  the  left-hand  side  of  a  rule.  The  representation  rAn 
of  a  knowledge  context  is  defined  as  for  term  tuples  (see  [6]  for  a  formal  definition).  We  write  “ A  ::  J”  to  indicate  that  A  is 
a  derivation  of  the  judgment  J. 

Lemma  6.2  Let  E  be  a  signature,  t  a  term  tuple,  and  A  and  A'  knowledge  contexts  compatible  with  E. 

If  >4::E;A  Ih  t  A',  then  •>  [rAn,  rt~l]  — **  [rA,_l]rS-,  is  derivable. 

This  result  is  proved  by  induction  on  the  structure  of  the  given  DAS  derivation  A  [6].  We  have  the  following  statement  for 
the  main  result  in  this  section. 

Theorem  6.3  (The  Dolev-Yao  Intruder  is  the  Most  Powerful  Attacker) 

Let  V  be  a  protocol  theory,  S  and  S1  two  states,  R  and  R'  two  active  role  sets,  E  and  S'  signatures  such  that 

hE  ELV  ELS  Eh  R  E  Ih  V  A  ::  E  Ih  R  A!  ::  E,  S'  Ih  R' 

If  Sv.V  >  [S]g  — >*  [S"]£'s„  then  (rVn,VDY)t>  [rSn]  ^  — ♦*  [rS"n]  is  derivable. 

where  E*  is  a  subsignature  of  S'  such  that  S'  =  E*,  El  and  El  consists  only  of  role  state  predicate  symbol  declarations. 

Proof:  This  proof  is  constructive  and  proceeds  by  induction  on  the  structure  of  £.  Due  to  space  constraints,  we  refer 
the  reader  to  [6]  for  the  technical  development  and  instead  give  the  intuition  behind  the  emulation  of  the  most  interesting 
execution  rules. 

Our  emulation  does  not  interfere  with  actions  that  involve  non-intruder  roles.  Installing  a  role  p1  anchored  on  I  into 
the  current  active  role  set  (rule  ex  arolc)  is  emulated  by  copying  as  many  instances  of  objects  from  V ,)y  as  specified  by 
the  encoding  of  p\  Intruder-instantiated  generic  roles  (rule  ex  grolc)  are  treated  in  the  same  way,  which  means  that  our 
emulation  does  not  allow  I  to  directly  execute  a  generic  role.  Uses  of  rule  ex_all  to  instantiate  a  universal  variable  in  an 
active  intruder  rule  do  not  correspond  to  any  action:  we  have  proved  that  DAS  is  preserved  under  substitution  [8]  and  that 
this  process  does  not  affect  the  encoding  of  a  DAS  derivation  [6].  Finally,  the  application  of  a  fully  instantiated  intruder  rule 
(ex_core)  relies  on  results  such  as  lemma  6.2  above  that  specify  the  behavior  of  its  constituents.  □ 

Since,  in  models  that  relies  on  black-box  cryptography,  an  attack  of  any  kind  is  ultimately  an  execution  sequence  between 
two  configurations,  this  theorem  states  that  a  security  protocol  has  an  attack  if  and  only  if  it  has  a  Dolev-Yao  attack.  This 
justifies  the  design  of  tools  that  rely  on  the  Dolev-Yao  intruder  [4,  14,  18,  20,  22,  24,  25],  but  it  does  not  mean  that  considering 
other  specifications  of  the  attacker  is  pointless.  Indeed,  precisely  because  of  its  generality,  a  straight  adoption  of  the  Dolev- 
Yao  intruder  often  results  in  inefficient  verification  procedures.  Overhead  can  be  greatly  relieved  by  relying  on  general 
optimizations  that  cut  the  search  space  [7,  13,  19,  24]  and  on  per-protocol  specializations,  for  example  allowing  the  intruder 
to  construct  only  message  patterns  actually  used  in  the  protocol  [20,  22],  Finally,  the  environment  in  which  a  particular 
protocol  is  deployed  may  be  so  constraining  that  a  weaker  attacker  model  is  sufficient  to  ensure  the  desired  security  goals. 

Our  result  extends  to  settings  that  involve  multiple  intruders  1 1 , . . .  In.  We  process  each  of  these  attackers  independently 
as  specified  above,  obtaining  n  copies  of  VDY,  each  anchored  on  a  particular  I  j.  We  then  make  use  of  the  attack-preservation 
result  in  [26]  to  reduce  them  to  a  single  attacker  I . 

7  Conclusions  and  Future  Work 

In  this  paper,  we  have  presented  a  data  access  specification  system  for  the  security  protocol  specification  framework 
MSR  [8,  9,  11]  and  used  it  to  show  that  the  Dolev-Yao  intruder  model  embedded  in  most  crypto-protocol  verification 
tools  [4,  14,  18,  20,  22,  24,  25]  is  indeed  the  most  powerful  attacker.  In  the  near  future,  we  intend  to  further  investigate 
the  relations  between  DAS  and  the  Dolev-Yao  intruder.  While  it  appears  that  a  specification  of  this  attacker  can  be  auto¬ 
matically  constructed  from  the  DAS  rules  [10],  it  is  not  yet  clear  whether  a  DAS  policy  can  always  be  derived  from  an 
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attacker  specification.  In  order  to  answer  this  question,  we  are  constructing  an  extended  library  of  case  studies  [8,  6,  9]  that 
require  different  DAS  assumptions.  Another  important  question  that  we  intend  to  tackle  using  MSR  is  whether  it  is  possible 
to  derive  sensible  DAS  rules  (and  a  most  powerful  intruder  model)  from  the  specification  of  a  protocol  (including  its  term 
language)  rather  than  by  imposing  them  from  above  [10].  On  a  more  practical  side,  we  want  to  address  the  issues  of  type- 
reconstruction  [9]  and  deterministic  variable  instantiation  in  order  to  develop  a  usable  security  protocol  verification  system 
based  on  MSR. 
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A  Example 


In  this  appendix,  we  show  an  actual  MSR  specification  by  reprinting  from  [9]  the  simple  protocol  theory  that  describes  the  two-party 
nucleus  of  the  Needham-Schroeder  public-key  authentication  protocol  [21],  We  choose  this  example  for  its  conciseness  and  the  fact  that 
most  reader  will  be  familiar  with  it.  More  complex  (and  interesting)  specifications  can  be  found  in  the  same  paper  and  in  [8]. 

The  server-less  variant  of  the  Needham-Schroeder  public -key  protocol  [21]  is  a  two-party  crypto¬ 
protocol  aimed  at  authenticating  the  initiator  A  to  the  responder  B  (but  not  necessarily  vice  versa).  It  is 
expressed  as  the  expected  ran  on  the  right  in  the  “usual  notation”  (where  we  have  used  our  syntax  for 
messages).  In  the  first  line,  the  initiator  A  encrypts  a  message  consisting  of  a  nonce  ua  and  her  own 
identity  with  the  public  key  kB  of  the  responder  B,  and  sends  it  (ideally  to  B).  The  second  line  describes  the  action  that  B  undertakes 
upon  receiving  and  interpreting  this  message:  he  creates  a  nonce  ub,  combines  it  with  A’s  nonce  ua,  encrypts  the  outcome  with  A’s  public 
key  /ca,  and  sends  the  resulting  message  out.  Upon  receiving  this  message  in  the  third  line,  A  accesses  nB  and  sends  it  back  encrypted 
with  k,B •  The  run  is  completed  when  B  receives  this  message  and  successfully  recognizes  nB- 

MSR,  like  most  modern  security  protocol  specification  languages,  represents  roles,  i.e.  the  sequence  of  actions  executed  by  each  indi¬ 
vidual  principal.  We  now  express  each  role  in  turn  in  the  syntax  of  MSR.  For  space  reasons,  we  will  typeset  homogeneous  constituents, 
namely  the  universal  variable  declarations  and  the  predicate  sequences  in  the  antecedent  and  consequent,  in  columns  within  each  rule;  we 
will  also  rely  on  some  minor  abbreviation. 

The  initiator’s  actions  are  represented  by  the  following  two-rule  role: 


1.  A  ^  B:  griA  AJkB 

2.  B  ->  A:  griA  nB^kA 

3.  A  — *•  B:  \nB^kB 


/  3L  :  principal  X  principal1-^  X  pubK£?  X  nonce. 


\/B  :  principal. 
Wkg  :  pubK  B. 


3nu 4  :  nonce. 


VA 

\ 

n(-8>a  AJfcB) 

L(A ,  B ,  kg,  tia) 


V . . . 

Wca  :  pubK  A.  N(][nA  nBJkA) 

'x/k'A  :  privKA’A-  L(A,  B,kB,nA) 
\VriA  ,  tib  :  nonce. 


N(«nBJfcB)  I 


Clearly,  any  principal  can  engage  in  this  protocol  as  an  initiator  (or  a  responder).  Our  encoding  is  therefore  structured  as  a  generic  role. 
Let  A  be  its  postulated  owner.  The  first  rule  formalizes  line  (1)  of  the  “usual  notation”  description  of  this  protocol  from  A’s  point  of  view. 
It  has  an  empty  antecedent  since  initiation  is  unconditional  in  this  protocol  fragment.  Its  right-hand  side  uses  an  existential  quantifier  to 
mark  the  nonce  riA  as  fresh.  The  consequent  contains  the  transmitted  message  and  the  role  state  predicate  L(A,  B,  kB,nA),  necessary  to 
enable  the  second  rule  of  this  protocol.  The  arguments  of  this  predicate  record  variables  used  in  the  second  rule. 

The  second  rule  encodes  lines  (2-3)  of  the  “usual  notation”  description.  It  is  applicable  only  if  the  initiator  has  executed  the  first  rule 
(enforced  by  the  presence  of  the  role  state  predicate)  and  she  receives  a  message  of  the  appropriate  form.  Its  consequent  sends  the  last 
message  of  the  protocol. 

MSR  assigns  a  specific  type  to  each  variable  appearing  in  these  rules.  The  equivalent  “usual  notation”  specification  relies  instead 
on  natural  language  and  conventions  to  convey  this  same  information,  with  clear  potential  for  ambiguity.  We  shall  mention  that  most 
declarations  can  be  automatically  reconstructed  [9]:  this  simplifies  the  task  of  the  author  of  the  specification  by  enabling  him  or  her  to 
concentrate  on  the  message  flow  rather  than  on  typing  details,  and  of  course  it  limits  the  size  of  the  specification. 

The  responder  is  encoded  as  the  generic  role  below,  whose  owner  we  have  mnemonically  called  B.  The  first  rule  of  this  role  collapses 
the  two  topmost  lines  of  the  “usual  notation”  specification  of  this  protocol  fragment  from  the  receiver’s  point  of  view.  The  second  rule 
captures  the  reception  and  successful  interpretation  of  the  last  message  in  the  protocol  by  B\  this  step  is  often  overlooked.  This  rule  has  an 
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empty  consequent. 


/  3L  :  principal  x  nonce. 

\/kB  :  pubK  B. 

Vk'B  :  privK  kB. 

\/A  :  principal.  N(-Jn^  A^]<-B)  — >  3nB  :  nonce. 

Vn^4  :  nonce. 

\/k^ 4  :  pubK  A 


VB 


nBJkA) 
L(B,  ns) 


|V...  N(|nsJfcB) 

\Vng  :  nonce.  L(B,nB) 

Again,  most  typing  information  can  be  reconstructed  from  the  way  variables  are  used. 


j 


B  Typing  Judgments  and  Rules 
B.l  Typing  Judgments 


t  ::  t' 

£  b  t-.T 
£  b  T 

b  £ 

f  r 

£  b  t-.T 

r  b  f 


r  is  a  subsort  o/t' 

£  b  P 

Term  t  has  type  t  in  signature  £ 

£  b  S 

r  is  a  valid  type  in  £ 

T  F  rhs 

£  is  a  valid  signatures 

r  b  r 

r  is  a  valid  typing  context 

F  b  p 

Term  tuple  t  has  type  t  in  signature  £ 

£bP 

t  is  a  valid  type  tuple  in  typing  context  T 

£  b  R 

P  is  a  valid  message  predicate  in  signature  £ 

S  is  a  valid  state  in  signature  £ 

rhs  is  a  valid  rule  consequent  in  typing  context  T 

r  is  a  valid  rule  in  typing  context  F 

p  is  a  valid  rule  collection  in  typing  context  F 

V  is  a  valid  protocol  theory  in  signature  £ 

R  is  a  valid  active  role  set  in  signature  £ 


B.2  Typing  Rules 


r  is  a  subsort  of  t' 


-  ss_pr 

principal  ::  msg 


-  ss_nnc 

nonce  ::  msg 


-  ss_shK 

shK  A  B  ::  msg 


- ss_pbK 

pubK  A  ::  msg 


-  ss  pvK 

privK  k  ::  msg 


£  b  :  t  I  b  i  :  T  Term  t  has  type  r  in  signature  £  ( viz.  context  F  j 

£  b  t\  :  msg  £  b  :  msg 

-  mtp.cnc 

£  b  ti  t2  :  msg 


£  b  t  :  msg  £  b  k  :  shK  A  B 

-  mtp  ske 

£  b  {t}k  :  msg 
£  b  t  :  t'  t'  ::  T 

-  mtp  ss 

T,  h  t-.T 


£  b  I:  msg  £  b  k  :  pubK  A 

-  mtp_pke 

£  b  ffjffc  :  msg 

-  mtp_a 

(£,  a  :  t,  £;)  b  a  :  t 


£  b  r 


T  b  r 


r  is  a  valid  type  in  signature  E  ( viz.  context  V ) 


-  ttp_pr 

£  b  principal 
£  b  A  :  principal  £  b  B  :  principal 
£  b  shK  A  B 


■  ttp_shK 


-  ttp_nnc 

£  b  nonce 

£  b  A  :  principal 


-  ttp_msg 


£  b  pubK  A 


■  ttp_pbK 


£  b  msg 

£  b  k  :  pubK  A 
£  b  privK  k 


■  ttp_pvK 


h  E 


E  is  a  valid  signatures 


■  itp_dot 


b  • 


£  b  T  b  £ 

b  £,  a  \  t 


■  itp_a 


£  b  principal1'1'  x  r  b  £ 
b  £,  Li  :  principal1'1'  x  t 


■  itp_rsp 


£  b  principal1'1'  x  r  b  £ 


b  £,  M_  :  principal1'4'  x  r 


-  itp_mem 


19 


F  r 

l_  yi  p|_rpp  r  h  principal1'4-1  x  r  FT 

-  ctp_sig  -  ctp_x  ctp_rsp 

F  E  F  F,  x  :  t  F  F  ,L:  principal*'4-1  x  t 

Yj  \~  t  \  T  r  F  t  :  t  Term  tuple  t  has  type  r  in  signature  E  ( viz.  context  T ) 

E  F  t  :  t  E  h  [t/ x]t 

mtp_dot  mtp_ext 

E  F  ■  :  ■  >:  r  (/,/'):  t(x)  x  f 

r  h  t  r  is  a  valid  type  tuple  in  typing  context  T 

TFr  F,x:rFr 

ttp_dot  ttp_ext 

r .  r  f  r(x)  x  f 

EhPFhP  P  is  a  valid  message  predicate  in  signature  E  ( viz.  context  T ) 

E  F  t  :  msg  (E,  L;:r,E)Fi:r  (E,M_:r,E)F(A,t):r 

ptp  net  -  PtP  rsP  -  PtP  mem 

E  F  N(i)  (E,  L;  :  r,  S')  F  U(t)  (E,  M_  :  f,  S')  F  Mj4(f) 

E  b  S  r  h  Ihs  S  (viz.  Ihs)  is  a  valid  state  (viz.  predicate  sequence)  in  signature  E  (viz.  context  F ) 

E  F  S  S  F  P 

-  stp_dot  - stp_ext 

S  F  ■  E  H  (S,P) 

r  F  rhs  rhs  is  a  valid  rule  consequent  in  typing  context  F 

r  F  r  (I\  x  :  t )  F  rhs  p  |_ 

-  rtp_nnc  -  rtp_seq 

r  F  3  x-.T.rhs  r  F  Ihs 

r  F  r  r  is  a  valid  rule  in  typing  context  F 

r  F  Ihs  r  F  rhs  E  F  r  (r,  x  :  r)  F  p 

-  utp_core  -  utp  all 

r  F  Ihs  — >  rhs  F  F  Vx  :  r.  p 

r  F  p  pis  a  valid  rule  collection  in  typing  context  T 

r  F  r  (r,i:f)  F  p  r  F  r  T  F  p 

-  otp_dot  -  otp_rsp  -  otp_rule 

r  F  ■  r  F  3L  :  r.  p  T  F  r,  p 

E  F  P  V  is  a  valid  protocol  theory  in  signature  E 

E  F  V  (E,  A  :  principal)  F  p 

htp_dot  htp_grole 

E  F  ■  E  F  P,pVA 

(E,  A  :  principal,  E;)  F  V  (E,  A  :  principal,  E()  F  p 

-  htp_arole 

(E,  A  :  principal,  E7)  F  V,pA 

E  h  R  Ris  a  valid  active  role  set  in  signature  E 

(E,  A  :  principal,  E;)  F  R  (E,  A  :  principal,  T,')  F  p 

-  atp_dot  atp_ext 

Eh-  (E,  A  :  principals')  F  i?.,  pA 
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C  Other  Omitted  Rules 


C.l  Omitted  Access  Control  Rules 


A  >  e  >  A7  Merging  context  knowledge  A  and  term  tuple  e  yields  A' 

A  >  e  >  A'  A  >  e  >  A'  _ 

-  mas.dot  [j]  masukn*  [-J  mas_knP  |  DEL  | 

A  >  •  >  A  A  >  e,e  >  (A',e)  (A,  e)  >  e,  e  >  (A',e) 


r-A^A  t 


Given  knowledge  A,  principal  A  can  construct  term  t 


r ;  A  S-A4  r ;  A  £2 

-  cas.cnc 

r ;  A  S -»a  t2 


dup(A),  CMP 


r;  A  ^a  t  T;AA*a  k 
r ;  A  S-^a  {t}k 


cas_ske 


dup(A),  sec 


T-A^a  t  r;A^  k 

r ;  a 


cas_pke 


dup(A),  pec 


T-A^a  t 


Given  knowledge  A,  principal  A  can  construct  term  tuple  t 


r;A^  • 


cas_dot 


del(A) 


r;A<Kt  t  r;A^  t 
r;A^  (t,t) 


;ext 


dup(A) 


C.2  Omitted  Execution  Rules 


(rhs)s  i^>  (  Ihs)yy  Right-hand  side  instantiation 

([a/*]r/is)(Eia:T)  »  {lhs)v> 

-  ex  seq  -  ex_nnc 

(lhs)s  »  (Ihs) e  (3*  :  r.  rhs)s  »  (Ihs) S/ 


V  >  c  — >*  c' 


Multi-step  sequential  firing 


-  ex_itO 

V  >  c  — >*  c 


P  >  C  — >  C  V  >  c'  — >*  c" 

-  ex  itn 

P  >  c  — >*  c" 


21 


